"Chris Huff" wrote:
> I was thinking of having each bone have an ID number.
> Maybe limit the number of bones to 255...

That would be enough in most cases but eventually people would complain over
it like they currently do with the limit for color_maps.

> So for each vertex, you just have to store a 1 byte number
> and a floating point weight value for each bone that affects
> it. (ID 0 would be "no bone") Even the ID/weight pairs would be
> identical among many vertices, so they could share them. (there would be
> many vertices that only belong to one bone)

For a high quality mesh wouldn't that be a lot of data indeed?
(I'm not saying it is, I'm just asking.)

> how do you decide which bone affects the vertices when the
> fields intersect?

The fields would have S-curved strengths like blob components. For each
vector all weights would be adjusted to add up to 1 (or 100%).

> I think this method would have problems individually
> controlling things like an arm resting next to a flexing leg.

In the "home pose" limbs not affecting each other would have to be separated
with a little distance between them. For example the home pose could be
designed with the arms going to the sides instead of downwards. It would not
always be a perfect solution though.

I think the best approach is a combination of both methods (storing weights
and calculating weights based on fields). First the fields "roughly"
determine all the weights; then the individual weights can be adjusted and
fine-tuned by the user or by some tool.

I've read about a bone tool that used a similar approach. First fields were
used to assign all weights, then the user could adjust those weights. Seems
sensible.

> > Anyway, how would you define a bone?
>
> I was actually thinking of defining them with 4 points: two "home
> position" points and two "current position" points, and POV would
> compute the transformations.

Two points can't define an object's alignment in space. At least three
points are needed. With four points the twisting can be stored too. That
would be 4 points for the "home position" and 4 points for the current
position. However, the points for the current position doesn't have to be
stored, as they are only relevant for the current frame.

The 4-point alignment system is better than my idea with 2 matrix
transformations, as it's much more effective. The reason I thought of
matrixes is because that would be my own approach if I were to make a bone
system in POV-script. Actually my recent matrix question in p.a-u was about
this. I would use an inverse matrix for the "home pose" and then a forward
matrix for the "current pose".

> That should make things very easy to define. Maybe some kind of
> orientation vector would also be useful, so you could have a
> twisting from bone to bone, but that could probably be emulated
> with multiple parallel bones.

That seems to be an awkward way of doing it. When posing a figure it's
*always* relevant how the limbs are aligned. You can't just specify the
locations of the limbs and then hope they're facing in the right direction.
Go for two points plus two orientation vectors; that's the most sensible
approach.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message